Many organizations use enterprise-wide business applications to help conduct the operations of the organizations. These organizations have global operations with employees, suppliers, subcontractors, customers, competitors, government entities, and so on that are located throughout the world. The organizations use the business applications to track various types of information needed for the operations of the organizations. The organizations may track information including supply order and delivery information, product order and delivery information, scheduled meeting information, planning information, and so on. Often associated with such information is date and time information. It has been traditionally difficult to ensure that the date and time information is consistent across all time zones.
Some business applications provide very little support for handling the difficulties associated with operations that span multiple time zones. For example, a business application may store all date and time information in the local time zone of the person or computer that specified the date and time. As an example, a person in the Eastern time zone of the United States may enter a date and time into a business application, and the business application may simply store the date and time for the local time zone. Users of the business application who are not in the Eastern time zone might not know the actual time zone associated with the date and time of the meeting. If meetings were scheduled with people in other time zones, their calendars might be updated without taking into consideration time zone differences. So, for example, a meeting scheduled to start at 11 a.m. by someone in the Eastern time zone would appear to someone in the Pacific time zone of the United States to start at 11 a.m. Pacific time, rather than at the correct time of 8 a.m. Pacific time.
Other business applications may provide support for the different time zones of the users. For example, a calendaring application may track the date and time along with the time zone of the person who scheduled the meeting. Each person who is invited to the meeting would receive an electronic mail invitation with the start time of the meeting adjusted to that person's time zone. For example, the business application may track the local time zone of each person and adjust the date and time of an invitation to reflect the start time of the meeting in the local time zone of the invited person.
In addition to tracking the local time zone of each user, a business application may store rules indicating the effective dates and times of standard time and daylight saving time for each year for each time zone. The Olson database (named after contributor Arthur David Olson) and the system registry of MICROSOFT WINDOWS contain time zone rules intended for use by computer programs to adjust dates and times to account for differences in time zones. Each rule may also indicate an offset to add to a common time zone (e.g., Coordinated Universal Time (“UTC”) or Greenwich Mean Time (“GMT”)) to get the corresponding time for the time zone of the rule. For example, a rule for the Eastern time zone would indicate that the offset from UTC would be −5 hours effective at the start of standard time and −4 hours effective at the start of daylight saving time. So, a meeting scheduled for 1 P.M. GMT would be scheduled for 8 a.m. Eastern time if standard time was in effect on the day of the meeting.
An organization may need to specify the date and time of a meeting or other event far in advance. For example, a supervisor may schedule a recurring weekly telephone conference with subordinates located throughout the world for the next several years. Although the business application may add the meeting to each subordinate's calendar at the correct time for the subordinate's time zone, the rules for effective dates and times for daylight saving time or their corresponding offsets may change over time. As an example, in 2005 the United States decided to go to extended daylight saving time effective in 2007. Prior to 2007, the rule had been that daylight saving time was effective from the first Sunday in April until the last Sunday in October. However, after 2007, the rule is that daylight saving time is effective from the second Sunday in March until the first Sunday in November. Because of the change in the rule, meetings that were scheduled for 2007 using the old rule for a date that was previously during standard time, but was now during daylight saving time, would be scheduled for the incorrect time. For example, a recurring meeting scheduled for Monday, Mar. 12, 2007 at 1 p.m. GMT would be added to the calendar of a person in the Eastern time zone for 8 a.m. Eastern standard time according to the old rule. However, with the new rule, the recurring meeting would actually be held at 9 a.m. Eastern daylight time. As a result, the time for the meeting would be incorrect in the calendar for all those affected by the extended daylight saving time. Unfortunately, this change in the rule and other changes in rules cause significant confusion among users. In particular, a user may not know whether a date and time was set under the old or new rule and thus would not know the correct time of a meeting. Even if the user knew the correct time for a meeting and corrected the time on the calendar, other users trying to trying to schedule meetings with that user would not know if that user's calendar was correct and would not know the actual availability of that user.